Workflow Management Systems (WFMS) support the modeling and execution of business processes. Business processes executed within a WFMS environment specify which piece of work is carried out in what sequence. The individual pieces of work might be distributed across a multitude of different computer systems connected by some type of network.
IBM Web Sphere Business Process Choreographer represents such a typical modern, sophisticated, and powerful workflow management system. It supports the definition of business processes as a network of activities. The network, the process model, is constructed from a set of activities, which define the individual tasks that need to be carried out. Definition of a process graph is via a graphical editor, or a flow definition language, such as Business Process Execution Language for Web Services (BPEL4WS). In this language, the activities are described as Web Services, defined via the Web Services Definition Language (WSDL).
For performance reasons, different instances of the same business process model are carried out in parallel, because serializing the execution of different instances would severely limit the throughput of the system.
In general, the parallel execution of process instances does not create any problems. However, there are situations where the parallel execution of a set of process instances could result in inconsistent information managed by the process instances themselves or by the Web services invoked by such process instances.
As the workflow management system carries out the individual business process instances invoke the Web Services without any knowledge of what the invoked web services do, certain anomalies and inconsistencies in the data managed by the invoked Web Services may occur.
For example, it is possible that several business process instances executed in parallel invoke the same set of Web Services with the same set of data. If the invoked set of Web services use the passed information to update databases, it is possible that the information stored in a database shared between these process instances or in a set of databases becomes inconsistent due to the possibly interleaved update actions of the different Web services.
FIG. 1 shows a prior art WFMS system 10 that invokes several Web Services 12A-12C (1 to N) which access two different databases 14A, 14B, and respective tables 16 and 18. It should be noted that the usage of a database management system, in particular a relational database management, is for illustration purpose only; any other mechanism that provides for the storage, persistent or non-persistent, can be used. Those Web Services are defined as activities within an appropriate process model. When the WFMS carries out process instances of the process model, it navigates through the process graph, determines the appropriate activities, and invokes the associated Web Service. As shown, those Web Services update data in the shown databases; this is expressed symbolically by arrows pointing to the databases.
FIG. 3 illustrates, in a timeline from top to bottom, a prior art method wherein two different process instances update two tables 18 comprising redundant information for a single customer person within respective two different database systems 14A, 14B maintained according to prior art in an enterprise.
For example, assume that two business process instances are carried out for the same customer number “1234” as the result of two requests for the update of the address of the same customer number 1234. Let us further assume that the first request creates process instance 1 to change the address to Short Street, Dallas, and the second request creates process instance 2 to change the address to Middle Street, Dallas. In this case it is possible that the execution sequence of the different invoked Web services is the following: Process instance 1 invokes system 1, process instance 2 invokes system 1, process instance 2 invokes system 2, and process instance 1 invokes system 2. The net result is that the address of the customer with the customer number 1234 in system 1 is Middle Street, Dallas, and in system 2 is Short Street, Dallas.
A straightforward approach to solving this data inconsistency problem might be to change the implementation of the workflow management system in such a way that all process instances for the process model are carried out sequentially. This option is certainly not a good option for any workflow management system that needs to sustain a demanding load, as the performance of the WFMS is substantially decreased.
Thus there is a need for a method and a respective system for serializing the access to information which is stored redundantly in at least two datastores, which avoids inconsistencies in the two datastores while at the same time maximizes the degree of parallel execution of process instances.